home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1990 / Sep 90 / MacApp.Tech$ 9⁄7⁄90 / 1935-OP++ Revisited-Sep90 < prev    next >
Encoding:
Text File  |  1991-03-06  |  5.3 KB  |  108 lines  |  [TEXT/GEOL]
  1. Item    4655179                         7-Sept-90        04:44PDT
  2.  
  3. From:   D6187                           ObjectSoft, Barry Wilson,PRT
  4.  
  5. To:     DEREK                           White, Derek
  6.         MACAPP.TECH$                    MacApp Technical
  7.  
  8. Sub:    OP++ Revisited
  9.  
  10. Derek (& Kurt, Eric, Howard & MacApp Tech),
  11.  
  12. Thanks for your incredibly rapid comments to my posting. I have to admit that
  13. most of what I wrote was first written very late at night and I didn't mean to
  14. irk anyone. I agree with you, Eric, about the right tool for the right job, but
  15. then I still fail to understand why C++ garners widespread acceptance when
  16. Simula has the same features. I maintain that C programmers are just as
  17. religious about C as Pascal programmers are about their faith and this explains
  18. a lot more about C++ versus Object Pascal than simply looking at a list of
  19. features.
  20.  
  21. As for the list of enhancements I proposed, upon rereading I did notice some
  22. things that must have escaped me at the late hour. So I'd like to add some
  23. comments.
  24.  
  25. Private Methods & Fields
  26. My main reason for proposing that declarations of methods be allowed inside of
  27. implementations is that it really changes nothing about the language. In fact,
  28. if I hadn't been told otherwise, I would have tried to declare a method in an
  29. implementation long ago. Adding more syntax for fields and methods is certainly
  30. possible, and would give Object Pascal all of the options of C++ and more if
  31. desired. But if new syntax is to be added, I hope that some careful thought
  32. will go into selecting the form it takes. The syntax of Pascal should not by
  33. tinkered with lightly. I'm inclined to say that no committee should touch the
  34. language, and instead we should give Herr Professor Wirth a list of what we
  35. want and then sit back and wait.
  36.  
  37. Class Declarations
  38. I have to agree that allowing locally scoped class declarations is dangerous.
  39. If I declare a new type 'MyRecordType' in a local routine there is no problem
  40. with assigning a variable 'm: MyRecordType' to a global 'g', becuase the global
  41. couldn't have been declared. Having this same kind of checking for objects is
  42. problematic because assigning a MyListType variable to a TList variable is
  43. exactly the kind of thing that makes objects powerful. The compiler would have
  44. to include the scopes of the types in its criteria for assignment compatibility
  45. of objects. I think that as a feature it is probably not worth the effort nor
  46. the complexity it would add to the compiler.
  47.  
  48. Reusability
  49. The scheme I described doesn't really replace mixin classes or protocols
  50. because the global routines can't use method calls in any polymorphic way
  51. amongst the classes using them. Someone clever enough to use the class
  52. information available a runtime might be able to work around this though.
  53.  
  54. Scoping and Reusability
  55. I agree about the locally declared method not being polymorphic, but it could
  56. be an override. I suppose that one could avoid the method entirely and pass the
  57. object to a regular procedure that did the same thing. Since the local
  58. procedure can access the same fields and make method calls to the object it
  59. doesn't sound like local methods are really needed. However, if later versions
  60. of Object Pascal add privacy features, then being able to make a local method
  61. might make the difference.
  62.  
  63. The real problem I wanted to address with local classes and methods is the
  64. plethora of global junk that collects in OO systems in general. Code
  65. reusability is a great and noble goal, but sometimes you write code that you
  66. KNOW shouldn't be reused by anyone. Hopefully USES and classes in the
  67. implementation will go a long way towards fixing this. I've worked in totally
  68. object oriented environments where somebody's one-shot quick and dirty class is
  69. visible in the browser for everyone to see (and use). Soon you have more than a
  70. dozen of them, and they can't be removed or changed because they do get reused.
  71.  
  72. Operator Overloading
  73. I meant Method Overloading. I think that I did have something to say about
  74. operator overloading when I wrote the title late that night. But in the light
  75. of day I sure don't remember it.
  76.  
  77. Genericity
  78. Yes, what I proposed isn't parameterized types. But it solves the most common
  79. problem I have with MacApp at the moment. I hate changing MacApp because then I
  80. dread the next release. But then I find that I have to change MacApp to get the
  81. results I want. For instance, I wrote my own floating window code a while back,
  82. which is not surprisingly almost exactly the same as what was just released on
  83. the ETO CD. Now, if I want to keep in tune with Apple I have to change MacApp
  84. yet another time. A feature that let me easily slip a class in between two
  85. classes in the hierarchy would be a godsend, because I could just as easily
  86. take it back out again.
  87.  
  88. INHERITED versus TView(myWindow).IRes
  89. My problem is that I need to be able to do TView(SELF).IRes, which didn't work
  90. last time I tried it. I'll try first assigning SELF to a myWindow variable and
  91. see what happens. Maybe someone out there knows another way? I remember someone
  92. once discussing this same problem.
  93.  
  94. Taking back a feature
  95. I didn't really mean removing it, just changing its scope. Another nice feature
  96. of Eiffel that I wouldn't mind Object Pascal borrowing would be renaming
  97. features.
  98.  
  99. Well, another long link that started life as a short one.
  100.  
  101. Barry Wilson
  102. ObjectSoft, Inc.
  103.  
  104.  
  105.  
  106.  
  107.  
  108.